FAQ
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Frequently asked questions about Reticulum and RNode.
Contents
What's the current status?
From Current Status ↗ in the manual:
All core protocol features are implemented and functioning, but additions will probably occur as real-world use is explored. The API and wire-format can be considered complete and stable, but could change if absolutely warranted. The Python code, for which this documentation is written, and known as the Reticulum Network Stack, is the Reference Implementation of Reticulum. The Reticulum Protocol is defined entirely and authoritatively by this reference implementation, and this manual. It is maintained by Mark Qvist, identified by the Reticulum Identity <bc7291552be7a58f361522990465165c>.
Didn't the maintainer abandon the project?
No. Mark stepped back from public-facing support and online community interaction in December 2025cite-ref-1[1], but he is still actively developing Reticulum and related projects elsewhere.
Where does development take place?
Development of the reference implementation and related projects happens over Reticulum with rngit. New releases are published on Aleph and PyPI. The GitHub repositories are only public mirrors that receive irregular updates.
So what is …
Reticulum: A protocol enabling scalable, efficient, and secure networks with no central authority. Also generally refers to the entire project and associated systems.
RNS: Reticulum Network Stack; the reference implementation of Reticulum.
Shared instance: By default, RNS only starts once per machine, and all other programs connect to it. However, if the first one goes down, they all lose their connection. To prevent this, the RNS daemon (rnsd) can be run as a service or prior to any other application.
Sideband: A cross platform, Kivy powered, GUI messenger app. It includes image, voice, and telemetry features, including distributed telemetry and situation mapping.
Nomad Network: A terminal-based messenger app that also includes distribution net, page, and page viewing capabilities.
LXMF: Lightweight Extensible Message Format is a simple and flexible messaging format and delivery protocol that allows a wide variety of implementations, while using as little bandwidth as possible. It supports text or binary encoded information.
Distribution Net: An E2EE message store to allow storage of LXMF messages for offline destinations.
LXMRouter: The system that handles LXMF messages, and is run behind the scenes for Sideband, NomadNet, and MeshChat.
LXST: Lightweight Extensible Signal Transport is a real-time streaming format and delivery protocol that allows a wide variety of implementations, while using as little bandwidth as possible. Use cases include real-time voice communication, media streaming, broadcast radio, public address systems. It is currently in a very early alpha state.
RNode: RNode is a flexible digital radio transceiver that enables Reticulum over radio, including but not limited to LoRa.
How does routing work without authoritative systems?
Reticulum works by having local routing tables. When a destination announces its presence, it sends its address and the public key of its identity on all known interfaces. Each interface that sees it processes it and, depending on the interface mode, may pass it along.
When a "router" (transport node) processes an announce, it determines whether its path is better than the current path to the destination, and if it is, stores it as the next hop towards that destination. This means that when a router is handed a packet with an address, it knows the next step in the routing table, and only the next step. There is no global routing table, and paths are dynamically generated as network topology changes.
The details of how announces are propagated are complicated, but an important concept is "gateways" (transport nodes participating in path seeking). Any peer can query the network to ask if a destination is known, and gateways will attempt to find it by asking other gateways on the network.
Because of this, network segments can store only local announces and query the wider network for those it doesn't know. If you're familiar with DNS, this is not unlike a local name server that knows some local names but must query another server when a name is unknown. The major difference is that you don't need an upstream server, Reticulum can query the network as a whole.
How secure is Reticulum?
Short version
Used properly, Reticulum meets or exceeds industry standards. It has forward secrecy and uses proven cryptographic primitives in proven methods. If any of these standards become insecure, Reticulum is designed for easy replacement of cryptographic standards.
Used improperly, it remains encrypted using a slower, less secure standard with no forward secrecy. As most networking stacks use optional encryption, this makes Reticulum more secure by default.
Long version
Most sustained communication in Reticulum is performed over a link. These links are AES encrypted with an ephemeral key based on a DH key exchange. This provides fast, secure, forward secret encryption. Virtually every communication is signed, providing an assurance that the encrypted data and even exposed metadata is authentic.
With the exception of unrouted packets, mostly announces generated to distribute public keys and pathing information, all packets in Reticulum are encrypted. The only exposed information is a two byte header, a one byte context field, and the destination address. The header contains single flag, the header, propagation, destination, and packet types, and the number of hops. No other information is exposed. Basic packets don’t include the source address even in the encrypted data, and no router ever sees more than one hop in either direction, and unless the sender chooses to identify themselves, there is no way to determine the sender from the received packet.
From a risk management perspective, cracking the AES encryption on a single link will only reveal the communications from that link session. Cracking the asymmetric keys will only allow decryption of base packets and any key exchanges that were recorded by the attacker.
By avoiding novel encryption, Reticulum uses proven industry standards to create a secure network stack that avoids the attack vectors inherent in other stacks.
What do you mean by forward secret?
Forward secrecy means that if the encryption of a single exchange is broken, no other exchange is compromised. This means if not all traffic is sensitive, it’s possible that an attacker could spend days, months, or even years of machine time to decrypt a lunch order, and all other messages would remain secure.
What’s the legality of the system?
This is not legal advice, as even if a contributor were to be a lawyer, they are not your lawyer.
So long as encrypted communication is legal in your jurisdiction, it’s almost certain Reticulum itself is legal. Reticulum is always encrypted, so any law preventing encryption will affect its legality.
In many jurisdictions, transmitting encrypted data over the radio is restricted, especially in amateur radio bands. Any license will clearly state what can and cannot be done on the band, be it a public or private band.
Unlicensed bands vary greatly between band and jurisdiction. This can cover not just frequency, but duty cycle and radiated power (both in raw dBm and in directed power, taking into account a directional antenna). For example, Digikey provides some basic guidance regarding LoRa products, but even this requires substantial investigation to ensure compliance. Many of the supported RNode boards from LilyGO are both FCC certified and are within frequency and power limits for most regions.
If your jurisdiction has laws regarding "service providers" for E2EE messengers, the distribution network functionality of NomadNet can be disabled, turning a node into a router without any storage of user data (which is encrypted and unavailable to the server in any case). Similarly, a node doesn’t need to have a TCP server, further isolating the node from such restrictions.
Reticulum is as legal as any other system providing the same functionality, so laws regarding encryption over the Internet, radio, telephone, wire, broadcast, etc. all apply. This is a tremendously complicated field, and if there’s any question, a specialist attorney would need to be told the specific application in question.
Why don’t all nodes route data by default?
You may have seen that the docs say, “Every node can become a transport node, simply by enabling it in its configuration, but there is no need for every node on the network to be a transport node. Letting every node be a transport node will in most cases degrade the performance and reliability of the network,” and you might wonder why that is the case. Mark Qvist explains:cite-ref-2[2]
Routing traffic is not free, it requires some sort of knowledge, and obtaining that knowledge has a bandwidth cost associated with it, no matter how smart you get about it. At the bottom of it, information theory is really thermodynamics, and you don’t get a free meal in terms of energy. Information is energy, so by obtaining it, there will always be expenditure. In any network, that expenditure is bandwidth (which is, again, energy). Let all nodes route traffic, and you end up wasting huge amounts of bandwidth on path/routing/maintenance traffic for potentially hundreds of nodes that will never actually route any traffic. And in addition, routing efficiency will be much worse, most packets will likely need many more hops than optimal. You design some algorithm that tries to elect optimal routing topologies. You are now wasting all your bandwidth on that. There’s a physical limit too, in terms of how many nodes your network can now support, which gets exponentially smaller when your medium speed drops. Goodbye to using LoRa and similar. You then say, to [heck] with it, and just decide [to flood route] everything, and hope for the best. Well, you see what happens here too. In the end, the approach Reticulum takes is the most optimal, and the only solution that is scalable and functional in the real world, even over very low-bandwidth mediums.
What’s to stop someone from flooding the network?
As a routed network, a packet sent to a single destination would go through a single path and likely jam a single router. Sending packets to multiple other destinations would cause issues for local routers, but the larger network would be less affected as paths diverge. This is generally true of all routed networks, and proper interface settings and network topology can assist in a single router’s overload not affecting the wider network.
There is a conceptual threat behind using announces, which are propagated using rules closer to that of standard flood routing, but there are systems in place to mitigate this.
First, announces have a bandwidth cap. No matter the number of announces pending, a router will use the bulk of its bandwidth for transmitting messages, not announces.
Second, announce flood triggers special logic that prevents unknown destinations from broadcasting large numbers of announces, allowing known-good destinations to continue unimpeded operation and queuing any suspicious announces until they can be rebroadcast at a reasonable rate after the burst has concluded.
Third, individual servers can limit announce rates of all destinations, preventing a destination from announcing far more frequently than is useful.
There is also burst control in place for path requests.
What’s to stop someone from flooding the radio to prevent communication?
Nothing. This is a matter for local authorities, be it law enforcement or the private owner of the band. Electronic warfare is a major discipline and solutions to this issue are of international interest. That being said, radio direction-finding is a mature technology and RF power drops off quickly, so leading enforcement to a jammer is somewhat trivial; it’s like finding what light bulb was left on.
What are the system requirements for running a Reticulum node?
Most systems that can run Python 3 can run RNS without issues. Some systems may require manual compilation of the crypto libraries or a less secure pure-Python implementation.
Through experimentation, a major node can run on a single core in the GHz class with about 780 MB of RAM. This includes file transfer and other capability, but this is application specific, as Reticulum can load a file and transfer it, requiring the file be loaded into RAM, or stream it directly with a much lower overhead. At time of writing, major nodes are running on a 2 GB VM, a Pi 4, and a 2 GB Le Potato.
Improvements since version 0.9.5 of Reticulum has significantly improved memory consumption for both the core stack and Reticulum-based applications, and as an example, a major node handling more than 300 interfaces, and an average of 1000 active links at any given time currently uses about 250 MB of RAM. An LXMF propagation node with 50 connected peers, handling around 2 million messages per month will use around 280 MB of RAM.
The C++ port microReticulum allows constrained hardware like microcontrollers and single-board computers to become standalone Reticulum nodes. It can also produce binaries that run on Linux/macOS.
RNode
What RNode LoRa transceiver should I buy?
There are a ton of Reticulum-compatible options, see the Hardware page on this wiki and Supported Boards and Devices ↗ in the manual.
Some recommendations:
• nRF52-based boards are orders of magnitude more efficient than ESP32-based boards, while ESP32 boards have WiFi and more processing power.
• The Heltec WiFi LoRa 32 V3 is a popular option, as despite being roughly 10 times less efficient it is very cheap. If you look in the right places, it can come with a case and antenna, though neither are exceptional.
Whichever RNode you buy, make sure to get the right frequencies for your country, and check compatibility if you decide on a different one.
After you acquire your board, you will need to flash an RNode firmware.
What is the range of an RNode?
Line of sight.
The distance varies so wildly, that’s the best answer available. Tests from a node in a house to inside a car across hilly, wooded terrain had links available to around one kilometer. Some tests in major cities had a range of a hundred meters. SSH sessions have been successfully used over 16 kilometers. Much greater distances have been reported with more or less evidence available.
The location of the antenna will make a substantial difference, as will the intervening terrain. Models are only available for determining the effects of changes on a known system, not to estimate range whole cloth.
What is the power consumption of an RNode?
Depends on the hardware. ESP32 based devices idle at around 150 mA for planning numbers, and varies wildly with transmit power.
nRF52 based systems have dramatically lower idle power consumption.
How does RNode deal with duty cycle limits?
There are multiple airtime limit options available in the RNode interface options. See RNode LoRa Interface ↗ in the manual for details.
In the EU, RNode may be allowed relaxed limits:cite-ref-3[3]
en300/220 allows increased power and duty cycle in some bands if “advanced interference mitigation” and/or “polite spectrum acces” is implemented, or the device is “under control of a network access point”. Actual implementation into local law is not completely harmonised and varies from country to country, so you’ll have to do your own local research. But RNode does implement advanced interference mitigation techniques that conform to the performance set forth in the relevant ETSI standards if the interference avoidance option is turned on in the firmware. I’m not a lawyer, of course, so ultimately it’s anyones own judgement and responsibility of this, but at least wanted to make a note of this.
Why won’t my TX Power go over 17 / Radio State Mismatch
Many of the boards RNode supports technically support up to 20 dBm, but are only rated to 17 for continuous operation. The Semtech datasheets are clear they can only be run at 20 dBm at a small duty cycle, but can be frustratingly vague on the specifics. As an announce may take up to 30 seconds at slower data rates (where you’d be more likely to use high power) and the IoT model for LoRa tends to expect very short transmission times, it’s nearly certain an RNode at 20 dBm would damage itself nearly immediately. The firmware for the boards that only support 17 dBm continuous will cap the power, and if the software tries to push it further, the RNode will report the radio is at 17, and the software will see that as a Radio State Mismatch error.
To understand the issue, it’s important to note that 20 dBm is twice the power of 17 dBm. If, for example, the RNode draws an additional 100 mA when transmitting at 17, then it will, assuming linear efficiency (which is almost certainly incorrect) it will draw an extra 200 mA at 20. This is ~600 mW of heating as the theoretical radiated energy is 100 mW at perfect efficiency. However, the VSWR of many of the stock antennas reflect around half the transmit power, feeding that 50 mW directly back into the transmitter.
As wider advice, that 3 dB gain may gain up to 50% more range, but as a practical matter with RNodes a well-tuned antenna can reduce the loss in the antenna and add directional gain, allowing a carefully crafted RNode at 17 dBm to actually outperform one at 20 dBm while consuming basically half the current.
If increased power is required beyond antenna gain, there are other units that support 20 - 30 dBm continuous, and actively cooling the RNode may or may not make a difference, but if the RNode in your hands is limiting you to 17 dBm, it should be respected unless you’re willing to destroy a few in testing.
Note: As with all wikis, this information is only as accurate as the author. More accurate but still user friendly corrections are always welcome. – Mike
References